(19) 



3 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



IIINIIIIMH 

(11) EP 0 921 690 A2 



(43) Date of publication: 

09.06.1999 Bulletin 1999/23 



EUROPEAN PATENT APPLICATION 

(51) Intel * H04N 7/62 



(21) Application number 99200377.2 

(22) Date of filing: 30.08.1995 



(84) Designated Contracting Slates: 


(72) Inventors: 


AT DE FR GB 


• Sato, Takashi, tnternationaal Oetrooibureau B.V. 


Designated Extension Slates: 


E6S6 AA Eindhoven (NL) 


LT LV S! 


• Shah, Imran, Internationsal Oetrooibureau B.V. 




5656 AA Eindhoven (NL) 


(30) Priority: 07.09.1994 US 302144 






(74) Representative: van der Kruk, Wiliem Leonardus 


(62) Document number(s) of the earlier application(s) in 


INTERNATIONAAL OCTROOIBUREAU B.V., 


accordance with Art. 76 EPC: 


Prof. Holstlaan 6 


95927940.7 / □ 727 126 


5656 AA Eindhoven (NL) 


(71) Applicant: Koninklijke Philips Electronics N.V. 


Remarks: 


5621 BA Eindhoven (NL) 


This application was filed on 09 - 02 - 1999 as a 




divisional application to the application mentioned 




under INID code 62. 



(54) MPEG information signal c 

(57) A method of transmitting timing critical data via 
an asynchronous channel. The timing critical data can 
be an MPEG transport stream of packets. The asyn- 
chronous channel can be a computer or telephone net- 
work, a digital storage media such as a digital VCR, or 
a digital interface. The packets are processed serially 
through a remuxer to obtain a constant rate and deliv- 
ered to and consumed by one or more target decoders, 
for example, inside a TV set or in a set-top decoder. To 
prevent overflow of the transport buff ers i nside th ese de- 



coders, a single monitor-scheduler is provided which 
monitors the transport buffers and delivers lo each the 
packets wanted scheduled so as to avoid buffer over- 
flow and loss of information. The method also includes 
restamping the transport packets with new PCRs. The 
remuxing scheme is simple enough to implement on 
DVCR or other consumer applications. Also described 
is a method for recording the output stream which se- 
lects out desired program material and tags the trans- 
port packets with SOAtags. 



O 

o> 

CD 



O 
Q_ 
111 




> FIG. 1 



20 22 21 



Printed by Jouve, 7S001 PARIS (FR) 



SNSDOCID: <EP_ 



J1690A£J_> 



EP 0 921 690 A2 



f 



Description 

BACKGROUND OF THE INVENTION 



s [0001] The invention relates to a system for recording and playing back an MPEG information signal in tracks on a 
record carrier, and specifically a record carrier of the Digital Video Cassette Recorder (DVCR) type. 
[0002] An MPEG information signal comprises a succession or stream of transport packets, which includes a data 
compressed digital video signal and a corresponding data compressed digital audio signal (and sometimes data sig- 
nals), for broadcasting purposes or for transmission via a cable network. The MPEG information sicnal is in the form 

to of transport packets having either an equal length or a variable length in time. In both cases, however, a transport 
packet comprises 188 bytes of information, the first byte of which is a synchronization byte. 

[0003] A transmission such as an MPEG information signal in the form for recording on and reproduction Irorn a 
record carrier, such as a magnetic record carrier as a tape, require special measures to be taken in order to realize 
such kind of transmission via the known tape format. 

is [0004] Storing a packet sequence number has its advantages if an MPEG data stream is received having a constant 
bit or transport rate without any gaps between packets, and comprising a number of differentvideoprograms interleaved 
in the MPEG data stream. Generally, such data stream may have too high a bit rate for recording the total data stream 
on the record carrier. For example, the MPEG bit rate tor cable transmission is 45 Mbps, whereas the record carrier 
typically records with a 25 Mbps bit rate. The recording arrangement now comprises a program selector lor retrieving 

so one or multiple programs from the MPEG data stream so as to obtain the MPEG information signal for recording. As 
information corresponding to only one program is included in aMPEGIransport packet, such a program selector selects, 
which Is per se known, only those transport packets from the MPEG data stream that comprise information correspond- 
ing to wanted program(s). That means that some packets of the original MPEG data stream received are deleted. Upon 
reproduction, however, a valid MPEG video signal in accordance with the MPEG standard, however now comprising 

25 only the wanled programs, must be regenerated or recreated. Bya "valid" MPEG signal ortransport stream of transport 
packets of valid timing-critical-information is meant a stream that satisfies the following requirements: 

1 . The program clock reference (PCR) in the packet is OK. The PCR is, typically, a 33 bit value of a sample of the 
local clock in the transmitter encoder. The PCR is used for clock recovery so that in the decoder, the local clock 

30 can be sync'd to the encoder local clock. 

2. Accumulated change to each PCR through the network must be kept within the limit specified by MPEG 

3. The decoder transport buffers do not overflow. 



[0005] Such regenerated data stream should have the transport packets that were selected upon recording in the 
& same order. Upon recording a sequence number can be added to each transport packet received, also for any packets 
that will be deleted. The sequence numbers of the packets that are selected and stored may be stored in the third block 
section of the signal blocks in which a transport packet is stored. Upon reproduction, a sequence of numbers is retrieved, 
where subsequent numbers will not necessarily be next higher numbers. In that situation one or more dummy packets' 
must be inserted so as to regenerate the replica of the original MPEG data stream. 
- 40 [0006] It will also be apparent that a reproducing arrangement will be needed which is adapted to each specific 
embodiment of the recording arrangement, so as to enable a reproduction of the MPEG information signal recorded 
on the record carrier. 

[0007] The two related copending applications, whose full contents are incorporated herein by reference, describe 
such systems which solve a problem arising from the asychronous nature of a channel represented by the DVCR and 

« the necessity for preserving the timing critical data incorporated in the MPEG transport stream so that it can be recon- 
stituted as a valid MPEG information signal upon playback for reproduction on a conventional TV set. The systems 
described involve tagging transport packets of the MPEG data stream, before inputting to the channel, with timing 
information, and using the timing information at the output end of the channel to recreate the proper data timing, various 
schemes are described for packing the timing information tags with each or a plurality of transmission units of the 

so transport stream. Using this basic tagging mechanism, transport streams of various types can be recorded and played 
back without losing any of the information in the original transmission. Where the transport rate of the transport stream 
is unknown, or with gaps between the transport packets (i.e.. bursty), or the transport rate changes, then the referenced 
related applications describe ways of handling such dala streams. 

[0008] When, on the other hand, the transport rate of the incoming transport stream is constant and unknown, the 
55 related applications also describe schemes for handling this situation. Thus, using a combination of Time-Of-Arrival 
(TOA) and Sequence-Of-Arrivat (SOA) tagging as described in the related applications, an MPEG-2 transport stream 
of unknown but constant transport rate can be recorded and recreated on playback. In this case, however, there must 
not be any gaps between the transport packets at the input. 
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BRIEF SUMMARY OF THE INVENTION 

[0009] An object of the invention is a system for recording and playback of MPEG information using a DVCR. 
[0010] A further object of the invention is a system for generating a fixed-rate, constant transport slream from an 
incoming unknown transport stream, which is possibly at varying rate, and/or bursty. 

[0011] Another object ol the invention is a system for generating a fixed-rate, constant valid MPEG transport stream 
from an incoming unknown MPEG transport stream, which is possibly at varying rate, and/or bursty. 
[0012] Still another object of the invention is a remuxing scheme for MPEG transport streams which is simple enough 
to implement in DVCR or other consumer applications. 

[0013] In accordance with one aspect of the invention, thepackets are processed serially through a remuxer to obtain 
a constant rate and delivered to and consumed by one or more target decoders, for example, inside a TV set or in a 
set-top decoder. To prevent overflow of the transport buffers inside each o1 these decoders, a single monitor is provided 
which monitors all of the transport buffers and delivers to each the packets wanted timed in a manner that will avoid 
buffer overflow and loss of information This aspect of the method of the invention requires that the transport packets 
be restamped with a new PCR. Looked at from another view, this aspect of the invention basically involves remuxing 
the transport stream to a known and fixed case, and then applying the solution described in the referenced related 
applications for the case of a transport stream with a constant and known transport rate. 

[0014] The invention is not limited to application to an MPEG informatbn signal and car also be applied to asy- 
chronous channels other than a DVCR. in addition to transmitting MPE3 data streams, there are various other appli- 
cations that may require the transmission of timing critical data over an asynchronous channel. Asynchronous here 
means that the physical data rate of the channeNs differantfrom the transport rate, the rate of the data to be transmitted, 
so that the bitwise timing of data is not maintained through the channel transmission. 

[0015] In the MPEG transport stream as an example of tim:ng critical data, tie relative arrival lime of a datum which 
represents timing information of the transport stream, i.e., the PCR, must not be changed beyond a specified tolerance 
through transmission without changing the PCR value accordingly. This is because otherwise, the Phase Lock Loop 
(PLL) circuitry of a decoder will fail to regenerate the data clock, and the buffers may under/overflow. This problem of 
how to transmit timing critical data over an asynchronous channel without changing any datum to be transmitted also 
exists where the asynchronous channel is a computer network, a telephone network or a digital interface, e.g. P1394. 
[001 B] In accordance with another aspect of the invention, an improved remux method is described which does not 
have to perform ccmpl ex de-multipiexing/re-multiplexhg but relies instead on sch edu I in g each packet without changin g 
the order of the useful packets. This method offers the important advantage that the required hardware is much less 
expensive and thus easier to implement in low-cost consumer equipment. 

[001 7] The various features of novelty which characterize the invention are pointed out with particularity in the claims 
annexed to and forming a part of this disclosure. For a better understanding ot the invention, its operating advantages 
and specific objects attained by its use, reference should be had to ihe accompanying drawings and descriptive matter 
in which there are illustrated and described the preferred embodiments of the invention, wherein like reference numerals 
depict the same or similar components. 

BRIEF DESCRIPTION OF THE DRAWINGS 



[001 8] In the drawings: 

Fig. 1 corresponds to Fig. 1 8 of the second related application and shows a system for handling a transport stream 
with a known and constant transport rate, from both the recording and playback standpoints; 
Fig. 2 shows an example of the input and output data streams from the apparatus of Fig. 1 ; 
Fig. 3 illustrates a remuxing and DVCR recording system; 

Fig. 4 shows an example of the input and output data streams from the apparatus of Fig. 3; 

Fig. 5 is a schematic block diagram of a packet processor feeding apparatus with a target decoder; 

Fig. 6 is a block diagram of one form of remuxing system in accordance with the invention; 

Fig. 7 is a block diagram combining the system of Fig. 1 and the remuxing syslem of Fig. 6 as one form of another 

embodiment of the invention; 

Figs. 8A and 8B are graphs illustrating the effects of a remuxing scheme which does not monitor the transport 
buffer under two different conditions; 

Figs. 9A and 9B are graphs illustrating the effects ol a remuxing scheme which does monitor the transport buffer 
under the same two different conditions of Figs. 8A and BB. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[001 9] In order to better understand the invention, we will first describe the system described and claimed in the two 
related applications for handling a transport stream with a constant, known transport rate. 

£0020] Fig. 1 shows such a system applied to an MPEG application where R represents the transport rate of the 
MPEG data stream subdivided into transmission units in the form of a succession of transport packets from a digital 
interface (D-l/F). in the example given, the incoming transport rate is 45 Mbps, to be recorded on a D VCR at 25 Mbps, 
and then recreated as a valid MPEG signal at 45 Mbps, for playback on a standard TV set. 

[0021] The incoming data stream from D-l/F is received by a known tagging means 10 for tagging each incoming 
packet with a SDA tag requiring only a counter 11 incrementing at the arrival of each transport packet. The tagged 
packets then go to a selection means 1 2 for selecting the desired program material, and the selected packets stored 
temporarily in a local buffer 15. As explained in the referenced related applications, trickmode packets can be generated 
from the incoming transport stream at block 1 6 and intermixed with the desired program material by a MUX block 17 
at the desired transport rate for recording on the DVCR. The tagging bits are recorded onto the DVCR tape along with 
the corresponding transport packets using the extra bits available from the 2 to 5 sync blocks mapping as described 
in the related cases. 

[0022] On playback, each recorded packet is read out at its correct sequ ence according to the SOA stamp information 
under control of a read control block 20 via a local buffer 22. A DE-MUX block 21 acts to separate the packet stream, 
and the gaps formed by the non-selected program material packets in the output stream are filled in by supplying Null 
packets from a Null packet generator 23. During playback, each time a 'discontinuity' in the SOA tag is defected, it is 
assumed to have come from a transport packet that has not been recorded. These "missing" packets are replaced 
with the Null packets. All transport packets are thus output at the known and constant transport rate. 
[0023] Fig. 2 gives an example of the transport stream resulting. In the upper diagram, as an example, the input 
transport stream is a two program stream: programs A and B. We wish to record only program A, and hence strip out 
the B packets in the selection block 1 2. On playback, all the packets belonging to program Aare reproduced at precisely 
their original times and rates, and the gaps are filled in with the Null packets (lower diagram). If the input stream was 
a valid MPEG signal, Ihe output stream will also be valid. 

[0024] As will be clear from the foregoing explanations, to maintain the interoperability between MPEG applications, 
it is necessary for the DVCR to generate a valid MPEG transport stream, preferably at afixed-rate and constant {i.e., 
withoul any gaps between packets). Generating a fixed-rate constant transport stream for input to the apparatus of 
Fig. 1 from an incoming unknown transport stream, which is possibly at varying rate and/or bursly, meaning thai there 
are gaps between the packets, is equivalent to generating a new transport stream by so-called remuxing. Remuxing 
by DVCR is comprised of selection of necessary packets, rescheduling of the timing of each packet, and multiplexing 
of the selected packets with Null packets to fill out the gaps in the transport stream. Whenever remuxing is done, ihe 
following remux requirements must be met: 

(a) Timing jitter of each PCR (incorporated in each transport packet) must be kept within an acceptable limit. 

(b) Accumulated change to each PCR Ihrough the network must be kept within the limit specified by MPEG. 

(c) Generated transport stream must nol overflow the transport buffer of each elementary stream decoder. 

[0025] One form of apparatus according to the invention is illustrated in Fig. 3, a combination of BOA and remuxing. 
In this case, after the remuxing 80, the packet stream at the new rata is tagged 61 and any Null packets removed in 
the local buffer block 82. However, in this case, the duration of the output packets ie different. Fig. 4 shows in the upper 
diagram the input stream to the remuxer 80, and in the iower diagram the output stream to the D-J/F. The transport 
rate is now constant but the packets need restamping with new PCRs because the old PCRs are no longer valid. 
Another problem appears, illustrated in Fig. 5. 

[0026] Fig. 5 shows schematically a valid MPEG signal input to a packet processor B4, which may be the system of 
Figs. 1 and 3. It outputs a valid transport stream like that of Fig. 4 (lower diagram) to. for example, a selector 86 selecting 
packets for each elementary stream decoder 85 which includes a transport buffer 87, referred 1o herein as the 'target 
decoder' and "target buffer". For the system to perform properly, the target buffers of each decoder provided must all 
be managed to avoid overflow. The problems are illustrated in Figs. 8A and SB. 

[0027] In these figures, X represents the input transport rate, Y represents the output transport rate, and R represents 
the read-out or emptying or leak rate of the transport buffer in fie target decoder. Fig. 8A shows the effect of remuxing 
without monitoring ol the transport buffer where R < Y < X. The row labelled. Input is the sequence of input transport 
packets, and the row below labelled output is the sequence of output transport packets over a time t. The graph above 
indicates the fullness of the transport buffer over time t, with the dashed fine 29 at top labelled Th representing a full 
buffer, and the dotted diagonal lines 30 representing the input stream. Where the solid line curve 31 representing the 
output stream crosses the threshold line 29, shown at 32, bits of certain output packets will be lost, which will occur 
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with packets 7, 1 0, etc. The case illustrated is where the input rate is faster than the output rate. 
[0028] In Fig. BB, the case where the input rate is slower :han the outpul rate is given, represented by R < X < Y 
with the doted lines 34 again representing the input stream, and the solid line curve 35 again representing the outpul 
stream. Here, too, without monitoring, when Ihe curve 35 crosses the threshold line 29, shown at 36 and 37, bits ol 
5 certain output packets will be iost, which will occur with packets 6, 9, etc. 

[0029] A feature of the invention is a remuxing scheme for MPEG transport streams which is simple enough to 
implement on DVCR or other consumer applications. 

[0030] This aspect of the present invention is based upon the following new concepts and understandings. 

io , 1. Incoming transport streams have small enough timing jitter, hence, requirement (a) can be met simply by re- 
stamping PCR's, using an appropriate focal clock. 

2. Incoming transport streams have enough head room for the PCR change; hence, the requirement (b) can be 
met by the remuxing scheme described below. By "head room" is meant the unused portion of Ihe limit as defined 
in the MPEG standard. 

1B 

[0031] General remuxing includes clock regeneration of each program, de-multiplexing of the input to separate each 
elementary stream : keeping track of each transport target buffer, calculation of a new schedule, re-multiplexing of the 
elementary streams, reetamping of PCR, and so on. As will be recognized, such general remuxing requires complex 
software and hardware not implementable in typical low-cost consumer appliances. A feature of our invention is based 
so on a simpler remuxing scneme, which does not perform de-multiplexing/re-multiplexing but simply schedules each 
transport packet without changing the order of the useful packets. This approach requires certain basic assumptions: 

1 . The total nel rate of the wanted program(s) in the input transport stream must be less than the output transport 
stream rate {the remux rale); 
£5 2. The input transport stream rate can, however, be unknown, bursty and/or at any rate, higher or lower; 

3. The remux rate is known, fixed and constant. 

[0032] In accordance with an aspect of the method of the present invention, the remuxing goes as follows, reference 
being made to Fig. 6 which is a block diagram of one form of remuxing apparatus in accordance with the invention: 

so 

1 . The necessary packets are selecled from the incoming transport stream by a Filter or selector 40. 

2. The packets containing the PCR are tagged 41 with the sampled value ol a bcal clock 39. 

3. Each packet is stored and kepi in a local buffer 42 until it is read out to a packet store 44. 

4. Whenever the packet store 44 is empty and there is at least one packet in the buffer 42, the first packet in the 
35 buffer 42 is read out and moved to the packet store 44. Necessary information of the packet is sent to a scheduler 

45 at the same time. 

5. The scheduler 45 checks whether outputting of the packet h the packet store 44 will overflow ihe transport 
buffer 87 of the corresponding elementary stream decoder 85 (Fig. 5) and signals it to a MUX 47 

6. If the packet store 44 has a packet and the schedule' 45 signals that the decoder transport buffer will be OK, 
40 the MUX 47 selects and reads out the transport packet in ihe packet store 44. Otherwise, the MUX 47 selects and 

outputs a Null packet from a Null packet generator 49. The packet in the packet store 44 remains there until It Is 
read out. 

7. Each PCR value in the transport packet transmitted by the MUX is modified in a PCR restamper 50 using the 
following equation: 

45 

PCR new = PCR oId + (Clock ounEnt - Clock te9gBd ) - Delay mM (1 ) 

where, 

so 

PCR naw : New PCR value after restamping; 
PCR old : Old PCR value before restamping; 
Clockeurre,,, : Current Clock value at output time restamping 50; 
Clocl4gg Bd : Clock value tagged 41 at reception of the packet; 
55 Delay max : Maximum delay through the remux operation, which is a constant value to ensure that each PCR value 

never increases. 
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[0033] The scheduling scheme is an important feature of this invention. The main purpose of scheduling is to ensure 
that the transport buffers in the decoders never overflow. Scheduling of packets takes a lot of work if it is done in a 
brute force manner because it involves keeping track of the transport buffer fullness of every elementary stream in 
parallel. This may be too complicated for consumer applicalions apparatus, hence, we created a simpler way to do the 
job. This is based upon the following; 

1. We can derive the transport buffer (85-88 in Fig. 5) emptying or leak rale (read-out rate) of each elementary 
stream Irom the information carried in the input transport stream. For example, the transport buffer leak rate is 54 
Mbps for the Grand Alliance HD Video standard, f 8 Mbps for SD Video and 2 Mbps for Audio, etc. We Ran know 
that if the remux rate is less than the transport buffer leak late, no transport buffer monitoring is necessary because 
the transport buffer never overflows. Hence, we can reduce the number of transport buffers that we need to monitor. 
Transport buffer monitoring can be further simplified using the following approaches: 

1 . The buffer fullness of each transport buffer increases monotonically from the beginning of each received packet 
through the end of the packet; hence, w© need to check the buffer fullness only at the end of each packet. 

2. Rsmux knows its own output transport rate (the remux rate) as well as the transport buffer leak rates for each 
elementary stream; hence, it can know how much the buffer fullness of a transport buffer will change by sending 
a packet and by not sanding a packet to the transport buffer, using the following equations: 



(2) 



Leak : Change of transport buffer fullness per one-packet period when transport buffer receives no packet; 

R leak ; transport buffer leak rate; 

Tp aoke , : Packet period, i.e., S paofce /R mmill( ; 

S paBket : Packet size; 

R remux :Remux rate; 

Delta : Change of transport buffer fullness per one-packet period when transport buffer receives one packet. 



below shows an example of a parameters table thai can ba used for transport buffer monitoring. 




Rate l6ak 


Leak bite (bytes) 


Delta bits (bytes) 


SD 
Audio 

Others >R remu)( 


18 Mbps 
1 Mbps 
Mbps 


1,062(135) 
61 (8) 
NA orO 


422 (53) 
1,443(180) 
NA or 0 



(Spacte, = 188 bytes, R ramuK = 25 Mbps) 

This table can be expanded if there are other data types which have known transport buffer leak rates and require 
transport buffer monitoring. 

3. Using the above results, the buffer fullness of each transport butter can be calculated using the following equa- 
tions: 



B pre v = B |a3t (i)-L e ak(i)( CcU! 



i : Index of the elementary stream which the current packet bebngs 1o; 

Bprev : transport buffer fullness of the i-th elementary stream just before receiving the current packet; 
B|ast(i) : transport buffer fullness of the i-th elementary stream when the transport buffer has just finished re- 
ceiving the last packet; 
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Leak(i) ■ transport buffer leak rate of the i-th elementary stream per one packet period; 

Current : Value of ^P" 1 P acket counter forthe current packet; 

Ci^O) : Value of outpul packet counter tor the last packet of the i-1h elementary stream 

lf B pre v < °- B pre» = 0 



where, 

B ourren( : transport buffer fullness of the i-th elementary stream when the transport buffer has just finished 
receiving the current packet; . . . 

Della(i) : Change of transport buffer fullness of the i-th elementary stream by receiving one packet. 

[0034] The scheduling algorithm goes as follows in the preferred embodiment: 

Step 1 . At every interval T packet , check if a whole packet is in the packet store 44. If there is a packet (the current 
packet), go to Step 2, otherwise, go to Step 5 

Step 2 . Iflhetraneportbufferleakrateof the i-th elementary stream, to whichthe current packet belongs, isobtained 
forthe first time, calculate Leak(i) and Delta(i), using aquation (2) and equation (3), respectively, and initialize the 
parameters for transport buffer monitoring as follows, and go to Step 3: 

EW0 = O (7) 

C |ast (i)=C corrent . (B) 

Step 3 . Calculate B cuireil , corresponding to the current packet, using equation (4), equation (5) and equation (6), 
and go to Step 4. 

Step 4 . II B curTorrt is equal to or less than the transport buffer size, output the current packet and update the pa- 
rameters as follows and go to Step 6. Otherwise, go to Step 5: 

fWi) = B eurant (9) 
C las1 (i) = <=„,„,„,. ( 10 > 

Step 5 . Output a Null packet and go to Step 6. 

Step 6 . Increment the output packet counter as follows and go to Step 1: 



[0035] This simple scheduling scheme requires only aseries of simple calculations per each packet period regardless 
of the number of the elementary streams in the transport stream and yet can prevent transport buffer overllow from 
happening. Moreover, as will be appreciated, where the system of Fig. 6 is employed as the packet processor of Fig. 
5, it is capable of monitoring the buffer fullness in each of the target decoders B5 provided while delivering to them 
valid MPEG streams. This is because the above-notod algorithm can be executed each time a packet arrives at the 
store 44, because the scheduler 45 knows which data stream the packet belongs to, is keeping track of the packets 
of each separate data stream, and knows the leak rates of the respective transport buffers in the respective target 
decoders 85. Thus, in a serial packet processing system, a single scheduler is able to monitor multiple decoders. 
[0036] If we combine the remuxing scheme explained above in connection with Fig. 3 with the overall recording 
proposal described in the referenced copending application; and remove redundancy, we can obtain a total DVCR 
solution, which is illustrated in Fig 7. The same reference numerals as are used in Figs. 1 and 6 represent the same 
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components in Fig. 7. The new components which function similarly to those previously described include a packet 
sequencer tagger 60 corresponding to the tagger 10, a second local buffer B 61 corresponding to local buffer 15, and 
a MUX 62 which muxes tagged and restamped transpot packets with the trickmode and null packets in the recording 
part prior to recording on the media. Whereas the previous Null packets meant MPEG Null packets to create a valid 

s MPEG stream, these null packets 49 are used merely to fill gaps in the recording stream and serve no MPEG function. 
In the playback part, there is provided a filter 65 1hat serves to strip off undesiredfill packets and the resultant transport 
stream is stored in a local buffer C 66 corresponding to local buffer 22, a decoding packet store 67 and decoding 
scheduler 6B which performs the reverse functions of the scheduler 45 in the encoding part, and a MUX 69 correspond- 
ing to block 17. 

10 [0037] Recording then goes as follows: 



1 . The necessary packets are selected by the filter 40. 

2 The packets containing PCR are fagged 41 with the local clock 39. 

3. Each packet is stored and kept in local buffer A 42 until it read out. 

4. Whenever the packet store 44 is empty and there ie at least one packet in buffer A 42, the first packet in buffer 
A42 is read out and moved to the packet store 44. The necessary information of the packet is sent to ihe scheduler 
45 at the same time. 

5. The scheduler 45 checks whether oulputting the packet in the packet store 44 will overflow the target transport 
buffer of the corresponding elemenlary stream or target decoder, as described above, and signals itlothe MUX 62 

6. If the packet store 44 has a packet and the scheduler 45 signals that the target transport buffer will be OK the 
packet in the packet store 44 is read out. The packet in the packet store 44 remains there until it is read out ' 

7. Each packet containing PCR is restamped 50 its PCR value using equation (1). 

8. Each packet is tagged 60 with its packet sequence No., which may have discontinuity due 1o the scheduling 

9. Each packet is stored and kept in the local buffer B 61 until it is read out. 

10. The packets read out from the buffer B 51 are multiplexed 62 with trickmode packets 16 and, if necessary, null 
packets 49, according to a trickmode recording scheme. 

[0038] Playback goes as follows: 

1 . The necessary packets are selected by the filter 65. 

2. Each packet is stored and kept in the local buffer C 66 until it is read out. 

3. Whenever the packet store 67 is empty, a packet is read out from the buffer C 66 and moved to the packet store 
67. The Packet Sequence No. tag of each packet is sent to the scheduler 68. 

4. The scheduler 6B checks whether the Packet Sequence No. matches an internal packet counter {not shown or 
incorporated in the scheduler) and signals OK if bolh match. 

5. If the scheduler 68 signals OK, the MUX 69 selects and reads out the packet in the packet store 67. Otherwise, 
the MUX 69 selects and sends out a Null packet. Every packet is sent out at the remux rate. Fig. 7 thus combines 
the remux scheme of Fig. 6 with the necessary components to allow recording and playback from a DVCR. 

[0039] " Figs. 9A and 9B show the improvement obtained under the same conditions described above in connection 
with Figs. 8A and 8B, respectively. In essence, shown in Fig. 9A. the rescheduler has delayed blocks 7 and 10, etc 
(see arrows 75 and 76) long enough to prevent target buffer overflow. Similarly, blocks 6 and 9, etc. have been delayed 
at arrows 77 and 78 as shown in Fig. 9B to prevent overflow and loss of information. 

[0040] In this way, a DVCR can reconstruct at playback, without toss of information, a transport stream that has the 
rate and timmg exactly as scheduled by the remux at recording. With this scheme, the remux rate can be equal to or 
higher or lower than the recording rate as long as the net transport stream rate at the remux is equal to or less than 
the recording rate. Note that in the Fig. 6 embodiment, Null packets 49 are added. If substituted for the remuxer 80 in 
the Fig. 3 embodiment. Null packels would have to be deleted 82. This superfluous addition and deletion o) MPEG 
Null packets is avoided in the Fig. 7 embodiment. 

[0041] In the block diagrams of the figures, only the data flow is shown by the arrows. Those skilled in the art will 
understand that several of the blocks are interconnected for command and control signals that are not shown in the 
figure. 

[0042] As previously indicated, the invention is also applicable to other data formats and other ways of preserving 
the cntical timing data. It will also be appreciated that the circuitry and hardware to implement the various blocks shown, 
including software to the extent needed, will be evident to those skilled in the art not only from the detailed information 
supplied in the referenced related applications, but also from the below listed references: 

(1) European patent application no. 492,704 (PHN 13.546) 
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(2) European patent application no. 595,411 (PHN 14.241) 

(3) European patent application no. 608,946 (PHN 14.449) 

(4) Grand Alliance HDTV System Specification, Draft document, February 22, 1 994. 

(5) US patent specification no. 5,142,421 (PHN 13.537) 

[0043] While the invention has been described in connection with preferred embodiments, it will be understood thai 
modifications thereof within the principles outlined above wii: be evident 1o those skilled in the art and thus Ihe invention 
is not limited to the preferred embodiments but is intended to encompass such modifications. 



1. A method of processing a first transport stream of transport packets having a program clock reference (PGR) 
comprising plural bits representing valid timing-criticai-information, and of unknown transport rate that may be of 
varying rate or bursty, to form a second transport stream of transport packets of known constant rate and of valid 
timing-critical-information, comprising the steps: 



(i) providing a local clock, 

(ii) processing the transport packets ol the first transport stream in a serial manner while sampling the local 
20 clock when a bit of the PCR of each packet is processed and storing the sampled clock time for each packet, 

(iii) delaying the transport packets to avoid overflowing downstream buffers, 

(iv) when ready to deliver the transport packets without overflowing the downstream buffer, re-sampling the 
local clock at the time of the corresponding PCR bit and updating the PCR with the new sample time, 

(v) delivering the transport packets with updated PCRs to form the second transport stream. 

25 

2. The method of claim 1 , wherein the transport rate o ; the first transport stream is of the order of 50 Mbps and the 
transport rate of the second transport stream is of the order of 25 Mbps. 



3. A method of transmitting timing-critical data including a program clock reference (PCR) via an asynchronous chan- 
30 nel downstream to apparatus including a target buffer having a limited read-out rate, comprising the steps: 

(i) receiving the timing-critical data subdivided into a stream of successive transport packets, 

(ii) determining the arrival time of each of the transport packets, 

(iii) temporarily storing ihe transport packets, 

35 (iv) computing the times when individual transport packets can betransmitted downstream to avoid overflowing 

the target buffer, 

(v) computing the departure time of each of said transport packets and modifying the PCR accordingly, 

(vi) transmitting downstream the transport packets in accordance with the computations of step (iv). 

40 4. A method as claimed in claim 3, further comprising re-stamping the transmitted transport packets, before trans- 
mission, with a new PCR. 



5. A method as claimed in claim 3, further comprising: 



4S (1 ) selecting the desired packets from the incoming transport stream by a filter, 

(2) storing for the selected packets the sampled arrival time of a local clock, 

(3) storing the selected transport packets via a local buffer in a packet store, 

(4) whenever the packet slore is empty and there is at least one packet in the local buffer, reading out the first 
packel in the local buffer and moving same tc the packet store while simultaneously passing on to a scheduler 

so information concerning the packet, 

■ (5) computing in the scheduler whether outputting of the packet in the packel store will overflow the downstream 
larget buffer and signalling it to a MUX, 

(6) if the packet store has a packet and the scheduler signals that the target buffer will be OK, selecting in the 
MUX and reading out the transport packet in the packel store; otherwise, selecting in the MUX and outputting 

55 a Null packet from a Null packet generator, 

(7) modifying the PCR in the transport packet transmitted by the MUX in a PCR re-stamper using Ihe following 
equation: 



9 



EP 0 921 690 A2 



PCR ncw = PCR old + (Clocks, - Clock |aggsd ) - Delay^ 



PC R new : New PC R value after restamping; 
PCR dd : Old PCR value before restamping; 
Clock eurrent : Current Clock value at restamping; 
Clock teg9ed : Clock value tagged at reception of the packet; 

Delay,^ : Maximum delay through restamping, which is a constant value to ensure that each PCR value 
never increases. 

6. A melhod as ciaimed in claim 5, wherein said scheduler operates by knowing the read-out rate of the target buffer, 
by computing the downstream target buffer fullness at an output transport rate, and by delaying the transmission 
of any transport packets if the computation indicates lha' the target buffer will overflow. 

7. A method as claimed in claim 5, further comprising means to record the selected packets, further comprising the 
steps: 

(viii) tagging the transport packets having the modified PCR with a sequence of arrival (SOA) tag, 

(ix) transmitting the tagged packets to a recorder. 
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(54) MPEG information signal conversion system 

(57) A method of transmitting timing critical data via 
an asynchronous channel. The timing critical data can 
be an MPEG transport stream of packets. The asyn- 
chronous channel can be a computer or telephone net- 
work, a digital storage media such as a digital VCR, or 
a digital interface. The packets are processed serially 
through a remuxerto obtain a constant rate and deliv- 
ered to and consumed by one or more target decoders, 
for example, inside a TV set or in a set-top decoder. To 
prevent overflow of the transport buffers inside these de- 



coders, a single monitor-scheduler is provided which 
monitors the transport buffers and delivers to each the 
packets wanted scheduled so as to avoid buffer over- 
flow and loss of information. The method also includes 
restamping the transport packets with new PCRs. The 
remuxing scheme is simple enough to implement on 
DVCR or other consumer applications. Also described 
is a method lor recording the output stream which se- 
lects out desired program material and tags the trans- 
port packets with SOA tags. 
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